Split, Send, Reassemble: A Formal Specification of a CAN Bus Protocol Stack

“A Controller Area Network (CAN bus) is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other in applications without a host computer.” 1 Robert Bosch GmbH developed it in the 80s and published the latest release in 1991 [9]. The protocol is message-based and was designed specifically for automotive applications but is now also used in other areas such as aerospace, maritime and medical equipment. The CAN bus was designed to broadcast many short messages to the entire network. The broadcast mechanism provides data consistency in every node of the system. Typical information sent are sensor data, such as speed or temperature. Due to its simplicity, it is easy to implement; however, its capabilities are rather limited, in particular w.r.t. payload and security. CAN Bus Limitations. In the CAN specification, version 2.0, there are two different message formats to send data in a (typical) CAN network [9]. The only difference between the two formats is that the standard frame format supports a length of 11 bits for the identifier, and the extended frame supports a length of 29 bits. The payload of both messages is 8 bytes only.2 CAN is a low-level protocol and offers no (standard) support for any security feature. Applications are expected to deploy their own security mechanisms. Failure to do so can result in various sorts of attacks. A lot of media attention was generated when cars were hacked and remotely controlled. The best security mechanism is to ensure that only trustworthy applications have access to the CAN bus. An alternative is the use of authentication and encryption, for instance through HMAC [7, 14] or GMAC [3]. The Need for Fragmentation and Reassembly. As soon as encryption and authentication is implemented, the messages used will be longer than 8 bytes; and even without encryption messages are often that long. Therefore there is the need for a fragmentation/reassembly protocol. In this paper we will present such a protocol on top of the CAN bus, which remains unchanged. One reason why we designed our own protocols is that they carry less overhead than off-the-shelf solutions.